PCT/EP200 4/0071 / 5 

BUNDESREPUBLIK* DEUTSCHLAND 



***** 



\ 





Prioritatsbescheinigung iiber die Einreichung 
einer Patentanmeldung 




Aktenzeichen: 
Anmeldetag: 
Anmelder/lnhaber: 
Bezeichnung: 



103 29 680.8 
01. Juli 2003 

University Stuttgart, 70174 Stuttgart/DE 

Prozessorarchitekturfur exakte Zeigeridenti- 
fizierung 



IPC: 



G 06 F 12/02 



Die angehefteten Stiicke sind elne richtige und genaue Wiedergabe der ur- 
sprunglichen Unterlagen dieser Patentanmeldung. 




EDV-L 



103396PDE 

Universitat Stuttgart 



Prozessorarchitektur far exakte Zeigeridentif izierung 



Technisches Anwendungsgebiet 

Die vorliegende Erfindung betrif ft eine Prozessor- 
architektur, bei der der Zugriff auf einen Speicher 
5 tiber Zeiger erfolgt, die auf Objekte verweisen. 

Die Beherrschung der Komplexitat von Software ist 
die grofite Herausforderung bei der Sof tware-Entwick- 
lung. Qualitativ hochwertige und zuverlSssige Systeme 
10 sind nur dann realisierbar, wenn es gelingt, Software 
in fibers chaubare und beherrschbare Module zu zerlegen 
und abstrakt zu beschreiben. Urn dies zu erreichen, 
werden seit einigen Jahren objektorientierte Program- 
miersprachen eingesetzt. 
15 Ein zentrales Problem bei der Implementierung 

objektorientierter Programmiersprachen ist die dyna- 
mische Speicherverwaltung. Einige wenige objekt- 
orientierte Sprachen wie z. B. C++ bauen noch auf 
manuelle Speicherverwaltung, d. h. dass Speicher unter 
20 der Verantwortung des Programmierers sowohl angef order t 
als auch wieder frei gegeben wird. Dieser Ansatz hat 
jedoch den Nachteil, dass die problemangepasste, 
natarliche Modellierung eines Systems oft nicht moglich 
ist, da beim Entwurf des Systems auch die Speicher- 
25 verwaltung realisiert werden muss. Weiterhin ist die 
manuelle Freigabe von Speicher Ursache einer ganzen 
Klasse von Programmf ehlern. Wird bspw. ein Speicher- 
bereich freigegeben, obwohl noch Verweise auf diesen 
Speicherbereich existieren, kann dies im weiteren 
Prograramablauf katastrophale Folgen nach sich ziehen. 
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Besonders gravierend ist hierbei, dass die Folgen der 
durch die noch existenten Zeiger auf den bereits frei 
gegebenen Speicherbereich (sog. dangling references) 
verursachten Fehler von vielen Faktoren abhangen und 
5 deshalb kaum zu reproduzieren und nur schwer zu loka- 
lisieren sind, Aus diesen Grtinden bauen fast alle 
modernen Programmiersprachen, wie bspw. Java, auf 
dynamische Speicherverwaltung mit autoinatischer 
Speicherbereinigung (sog. garbage collection) . In 

10 Systemen mit dieser dynami s chen Speicherverwaltung 

kSnnen Speicherbereiche nicht unter Verantwortung des 
Programms zuruck gegeben werden. Statt dessen gibt ein 
Speicherbereiniger (garbage collector) die Speicher- 
bereiche automatisch erst dann frei, wenn sie von einem 

15 Programm sicher nicht mehr referenziert werden. Dadurch 
k6nnen prinzipbedingt keine "dangling references" 
auftreten. Weiterhin erhoht der Einsatz dieser Technik 
die Produktivitat der Programmierer, da diese sich nun 
vollstandig der L6sung des eigentlichen Problems widmen 

20 kSnnen. Schliefclich ist die erstellte Software von 

h6herer Qualitat, da die Wahrscheinlichkeit versteckter 
Programmfehler in einem System mit dynamischer Spei- 
cherverwaltung deutlich geringer ist als in einem 
System mit manueller Speicherverwaltung. 

25 



Stand der Technik 

Fur die automatische Freigabe dynamisch angelegter 
30 Speicherbereiche existieren zahlreiche Algorithmen, die 
dem Fachmann unter den Begriffen Reference Counting, 
Copying und Mark Sweep Collection bekannt sind. Fur 
einen ttberblick liber diese Algorithmen wird auf R. 
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Jones, R. Lins: „Garbage Collection: Algorithms for 
Automatic Dynamic Memory Management *, John Wiley & 
Sons, 1996, verwiesen. 

5 Einfache Implement ierungen dieser Algorithmen 

unterbrechen das Anwendungsprogrammm ftir die gesamte 
Dauer eines Speicherbereinigungszyklus • Sie verursachen 
in der Regel lange und unvorhersehbare Pausen in der 
Programmausftihrung und sind deshalb nicht fur inter - 

10 aktive Systeme oder Echtzeitumgebungen geeignet. 

Inkrementelle und nebenlauf ige Verfahren erlauben 
es, die Programmausfuhrung wahrend eines Speicherberei- 
nigungszyklus fortzusetzen. Sie erfordern allerdings 
die Synchronisation zwischen Anwendungsprogramm und 

15 - Speicherbereiniger. Die Kosten dieser Synchronisation 
in Software sind jedoch erheblich, da, je nach verwen- 
detem Verfahren, entweder vor jedem Laden eines Zeigers 
(read barrier) oder vor jedem Speichern eines Zeigers 
(write barrier) eine kurze Codesequenz eingeftigt werden 

20 muss, um f estzustellen, ob das zugehSrige Objekt vom 
Speicherbereiniger bereits bearbeitet wurde. 

Viele inkrementelle Verfahren werden als „echt- 
zeitfahig* beschrieben, weil die vom Speicherbereiniger 
verursachten Pausen in den meisten Fallen zu kurz sind, 

25 vim vom Anwender regis triert zu werden. Harte Echtzeit- 
fShigkeit erfordert jedoch die Garantie einer kons tan- 
ten oberen Schranke ftir die Antwortzeit eines Systems. 
Da sof tware-basierte Verfahren in der Regel auf nicht 
unterbrechbare Operationen wie die Untersuchung aller 

30 Zeiger der Wurzelmenge (Register und Stapel) oder die 
Bearbeitung eines vollstfindigen Objekts angewiesen 
sind, genugen sie harten Echtzeitanf ordeirungen nicht. 
Es sind zwar Sof tware-L5sungen bekannt, die ohne ato- 
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mare Operationen unbeschrankter Dauer auskommen, jedoch 
ist der Overhead dieser Losungen an Rechenzeit und 
Speicher erheblich. 

5 Ein grundsatzliches Problem aller Techniken zur 

automatischen Speicherbereinigung besteht im Auf finden 
und Identif izieren von Zeigern. Wenn Zeiger nicht ein- 
deutig von Nicht-Zeigern unterschieden werden konnen , 
so lasst sich lediglich eine konservative Speicher- 

10 bereinigung durchftihren. Dies bedeutet, dass jedes 

Bitmuster, das einen Zeiger darstellen konnte, aucb als 
Zeiger betrachtet werden muss, urn die Freigabe von noch 
in Benutzung bef indlicbem Speicher zu vermeiden. Bei 
einer konservativen Speicherbereinigung diirf en daher 

15 keine kompaktierenden Verfahren eingesetzt werden, die 
Objekte verschieben und Zeiger aktualisieren. Ohne kom- 
paktierende Verfahren wird der Speicher jedoch fragmen- 
tiert . 

Zur Vermeidung dieser Problematik und zur Durch- 
20 ftihrung einer exakten Speicherbereinigung wird ein 

groSer Aufwand bei der Suche und Identif izierung von 
Zeigern betrieben. Bei vielen objektorientierten Spra- 
chen konnen Zeiger in Objekten uber Typbeschreibungen 
(type descriptors) identif iziert werden, die in jedem 
25 Objekt enthalten sind. Die Lokalisierung von Zeigern im 
Programmstapel sowie in den Prozessorregi stern ist 
jedoch schwieriger, insbesondere im Zusammenhang mit 
optimierenden Compilern. Es ist zwar moglich, Daten- 
strukturen zu unterhalten, in denen die Stapelpositio- 
3 0 nen und die Prozessorregister angegeben sind, die 

momentan Zeiger enthalten, jedoch sind die Kosten zur 
Aktualisierung derartiger Datenstrukturen wahrend der 
Programmaus ftihrung sehr hoch. Aus diesem Grund ver- 
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wenden die meisten sof tware-basierten Verfahren vom 
Compiler erzeugte Tabellen, die die Lage der Zeiger im 
Programmstapel sowie in den Regis tern beschreiben. Fur 
jeden Programmpunkt , an dem eine Speicherbereinigung 
5 durchgeftihrt werden konnte, wird ein Satz derartiger 
Tabellen erstellt. Die Realisierung dieser Technik 
ftihrt jedoch zu einem betrachtlichen Aufblahen des 
Programmcodes . Weiterhin mtissen Echtzeitsysteme sicher 
stellen, dass zu suspendierende Threads den nSchsten 
10 derartigen Programmpunkt innerhalb einer begrenzten 
Zeitspanne erreichen. 

Mit den bisher bestehenden Systemen, die in erster 
Linie auf eine automatische Speicherbereinigung in 

15 Software setzen, miissen somit zahlreiche Probleme 

bewaltigt werden. Dies beruht vor allem darauf , dass 
die Software Funktionen nachbilden muss, die die 
zugrunde liegende Hardware nicht zur Verfugung stellt. 
Viele Probleme hinsichtlich Effizienz und Echtzeit- 

20 fahigkeit k6nnen behoben werden, wenn der Prozessor 

selbst die automatische Speicherbereinigung ganz oder 
teilweise in Hardware durchfuhrt. Daftir ist es jedoch 
zwingend erforderlich, dass der Prozessor Zeiger iden- 
tifizieren kann, 

25 

Im Folgenden werden von den zahlreichen bekannten 
Architekturen lediglich zwei beispielhaft angefiihrt, 
die eine exakte Zeigeridentif izierung und/oder automa- 
tische Speicherbereinigung untersttitzen und fur den 
30 Gegenstand der vorliegenden Erfindung von Bedeutung 
sind. 
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So sind seit 1966 Architekturen bekannt, die sog. 
Capabilities an Stelle von direkten Zeigern einsetzen, 
vim Speicherbereiche zu adressieren. Capabilities ent- 
halten Angaben zur Zugangsberechtigung und Identifizie- 
5 rung von Objekten. Sie enthalten nicht die physikali- 
sche Adresse des Objekts, sondern einen Verweis auf 
einen Deskriptor, der den Ort, die Grofie sowie weitere 
Eigenschaften des Objekts beschreibt. Ein Beispiel f\ir 
einen Prozessor mit einer derartigen Architektur ist 

10 der Intel iAPX 432, wie er bspw. in H. M. Levy: 

„Capability-Based Computer Systems", Digital Press, 
1984 , Seiten 159 - 186, beschrieben ist. In dieser 
Architektur wird eine Capabilitiy durch einen zweistu- 
figen Abbildungsprozess mit dem zugehSrigen Objekt 

15 assoziiert. Fur jedes Objekt existiert ein eindeutiger 
Eintrag in einer Objekttabelle, der den Ort, die GroSe 
und den Zustand des Objekts beschreibt. Jedes Objekt 
besteht aus zwei Bereichen: Einem Datenbereich und 
einem Bereich fur Capabilities. Auf diese Weise wird 

20 eine exakte Capability-Identif izierung ermSglicht. 

Durch das Fehlen eines Registersatzes und die 
doppelt indirekte Adressierung eines Objekts tiber 
Capabilities und Ob j ektdeskr iptoren ist der iAPX 432 
auEerst ineffizient. Weiterhin fiihrt er selbst keine 

25 automatische Speicherbereinigung durch. Die Speicher- 
bereinigung jnuss in Software erfolgen und ist nicht 
echtzeitfShig. 

Alle bekannten Verfahren zur Identif izierung von 
30 direkten Zeigern verwenden in jedem Speicherwort ein 
spezielles Kennzeichnungsbit (tag) zur Unterscheidung 
von Zeigern und Nicht-Zeigern. Ein Beispiel dafur ist 
das in der US 5,560,003 A beschriebene System und Hard- 
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ware-Modul fur inkremen telle Speicherbereinigung in 
Echtzeit, das sich aus zwei Speicherbanken und einem 
Lokalprozessor zusammensetzt, der die Speicherbereini- 
gung durchftihrt. Jede Speicherbank wird von einem sog. 
5 Ob j ektraum-Manager untersttitzt, der bei jedem Speicher- 
zugriff die Startadresse des entsprechenden Objekts 
ermittelt. Aufgrund seiner Komplexitat muss dieser 
Ob j ektraum-Manager als getrenntes ASIC realisiert 
werden, das eine ahnliche Chipflache beansprucht wie 
10 der Speicher selbst. Ein derartiges System ist sehr 

kostspielig. Weiterhin verursacht die Identif izierung 
von Zeigern mit Hilfe von Kennzeichnungsbits zusatz- 
lichen Aufwand in Form von Rechenzeit und Speicherbe- 
darf . 

15 

Wegen der standig steigenden Komplexitat der Soft- 
ware in eingebetteten Systemen werden seit einigen 
Jahren groSe Anstrengungen untemommen, die Vorteile 
der automatischen Speicherbereinigung auch diesem wirt- 

20 schaftlich wichtigen Bereich zuganglich zu machen. 

Gerade in diesem Bereich der modernen Informationstech- 
nik werden die gro£ten Stuckzahlen erzielt. Da die 
Produktzyklen durch standige Innovation immer ktirzer 
werden, steigt die Nachfrage nach robusten und echt- 

25 zeitfahigen Plattformen fur eingebettete Systeme far 

moderne objektorientierte Sprachen standig. Allerdings 
wird die automatische Speicherbereinigung fur diese 
Anwendungen in den meisten Fallen noch immer als ein 
Luxus betrachtet/ den man sich trotz der unumstrittenen 

30 Vorteile der automatischen Speicherbereinigung nicht 
leisten kann. 
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Ausgehend von diesem Stand der Technik besteht die 
Aufgabe der vorliegenden Erfindung darin, eine Prozes- 
sorarchitektur far objektbasierte und objektorientierte 
Programme anzugeben, die eine kostengtinstige exakte 
5 Zeigeridentifizierung ermoglicht und somit den Weg fur 
eine effiziente und echtzeitf ahige automatische 
Speicherbereinigung freigibt, die ganz oder teilweise 
in Hardware realisiert werden kann* 

10 Darstellung der Erfindung 

Die Aufgabe wird mit der Prozessorarchitektur 
gemaS Patentanspruch 1 gelost. Vorteilhafte Ausge- 
staltungen der Prozessorarchitektur sind Gegenstand der 
Unteranspruche oder lassen sich aus der nachf olgenden 
15 Beschreibung sowie den Aus ftihrungsbei spiel en entnehmen. 

Im Rahmen der vorliegenden Patentanmeldung wird 
der Begrif f Wort als Dateneinheit verstanden, die 
mittels einer einzigen Prozessoranweisung aus dem Spei- 

20 cber geladen oder im Speicher abgelegt werden kann. 

Unter einem Objekt wird eine zusammenhangende Menge an 
Speicherworten verstanden, in der jedes Wort exklusiv 
einem einzelnen Objekt angehort. Unter einem Zeiger 
wird ein Wort verstanden, das auf ein Objekt verweist. 

25 Der Begriff Null reprasentiert einen fest vorgegebenen 
Zeigerwert, der benutzt wird, urn auf kein Objekt zu 
verweisen. 

Bei der vorliegenden Prozessorarchitektur fiir 
30 objektbasierte und objektorientierte Programme erfolgt 
der Zugriff auf den Speicher ausschliefilich fiber 
Zeiger, die direkt auf Objekte verweisen. Ein Objekt 
wird in einem zusammenhangenden Speicherbereich exklu- 
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siv abgelegt, d. h. die von zwei Objekten belegten 
Speicherbereiche dxirfen sich nicht tiberlappen. In jedem 
Objekt werden Zeiger in einem Zeigerbereich und Daten 
in einem Datenbereich getrennt voneinander abgelegt. 
5 Dartiber hinaus werden in jedem Objekt Inf ormationen 
tiber die LSnge des Zeigerbereichs und die Lange des 
Datenbereichs abgelegt. Diese LSngeninf ormationen 
werden nachfolgend als Attribute bezeichnet. Mit Hilfe 
der Attribute ist es jederzeit m5glich, die Grofie eines 

10 Objekts zu bestimmen und die Zeiger und Daten in einem 
Objekt eindeutig voneinander abzugrenzen. 

Die vorliegende Prozessorarchitektur stellt 
getrennte Zeigerregister- und DatenregistersStze zur 
Verftigung. Dabei sind Zeigerregister ausschlieSlich fur 

15 Operationen mit Objekten wie bspw. ftir Speicherzugrif f e 
vorgesehen und werden nicht fur andere Aufgaben verwen- 
det. Dadurch wird insbesondere sichergestellt , dass 
keine beliebigen Werte in Zeigerregister geschrieben 
werden und keine arithmetischen Operationen mit Zeiger- 

20 regis tern durchgeftihrt werden kSnnen. 

Die Zeiger in den Zeigerbereicben der Objekte und 
in den Zeigerregi stern enthalten direkt die Adresse der 
Objekte im Speicber. 

25 Mit der vorliegenden objektbasierten Prozessor- 

architektur wird auf diese Weise eine strikte Trennung 
von Zeigern und Nicht-Zeigern (Daten) realisiert, 
sodass eine exakte Zeigeridentif izierung ohne die Not- 
wendigkeit von Kennzeichnungsbits mSglich ist. Durch 

30 diese von der Hardware sicher gestellte exakte Identi- 
f izierbarkeit der Zeiger in den Prozessorregi stern und 
im Speicher lasst sich eine automat ische Speicherberei- 
nigung auf Prozessorebene integrieren, die ganz oder 
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teilweise in Hardware implementiert werden kann. Auf 
dieser Grundlage werden echtzeitfahige Systeme mit 
automatischer Speicherbereinigung moglich, die beson- 
ders effizient implementiert werden konnen. So ist 
5 weder fur den Speicherbereinigungsalgorithmus selbst 
noch fur die erf orderliche Synchronisation zwischen 
Prozessor und Speicherbereiniger Software erforderlich, 
die auf dem Prozessor ausgeftihrt werden muss. Der Pro- 
zessor muss lediglich einen Teil der Speicherbandbreite 

10 an den Speicherbereiniger abtreten. 

Ein weiterer Vorteil der Architektur besteht 
darin, dass die Speicherbereinigung ohne die Koope- 
ration des Compilers und/oder des Lauf zeitsystems 
auskommt und deshalb besonders robust implementiert 

15 werden kann. 

Der Hardware-Aufwand fur die Realisierung der 
Speicherbereinigung ist gemessen am Aufwand fur den 
Prozessor selbst vergleichsweise gering. Aus diesem 
Grund konnen solche Prozessoren genauso wirtschaf tlich 

20 wie berkoramliciie Mikroprozessoren oder Mikrocontroller 
hergestellt werden. 

Vorzugsweise wird bei der vorliegenden Prozessor- 
architektur durch den Prozessor gewahrleistet , dass 

25 jedes als Zeiger identif izierte Wort entweder die 

Adresse eines existierenden Objekts beinhaltet oder 
Null ist. Bei dieser bevorzugten Ausgestaltung wird 
durch die Prozessorarchitektur somit die feste Regel 
(Systeminvariante) eingehalten, dass einerseits jedes 

30 Speicherwort oder Register dahingehend identif iziert 
werden kann, ob es ein Zeiger ist oder nicht, und 
andererseits jeder Zeigerwert entweder Null ist oder 
die Adresse eines existierenden Objekts enthalt. Durch 
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das Einhalten dieser Systeminvariante wird die exakte 
Identif izierung der Zeiger im System zu jedem Taktzeit- 
punkt ermoglicht. 

5 Vorzugsweise werden neue Objekte durch einen 

speziellen Ob j ekter zeugungsbef ehl angelegt, dem die 
Attribute des anzulegenden Objekts als Parameter 
ubergeben werden. Dieser Objekterzeugungsbef ehl initia- 
lisiert alle Zeiger des Zeigerbereichs mit dem Null- 

10 Wert, bevor auf das Objekt zugegriffen werden kann. Auf 
diese Weise wird die Systeminvariante nicht verletzt. 

In einer Weiterbildung fur harte Echtzeitanforde- 
rungen wird der Ob j ekterzeugungsbef ehl unterbrechbar 
implement iert, wobei beim Abbruch eines Ob j ekter zeu- 

15 gungsbefehls unvollst&ndig initialisierte Objekte 

derart erzeugt werden, dass der unterbrochene Objekter- 
zeugungsbef ehl zu einem spateren Zeitpunkt fortgesetzt 
werden kann und dass unvollstandig initialisierte 
Objekte vom Prozessor in eindeutiger Weise gekennzeich- 

20 net werden. 

Vorzugsweise werden von der Prozessorarchitektur 
konstante Objekte unterstxitzt, die bereits vor dem 
Programmstart als Teil eines nur lesbaren Speicherbe- 
25 reiches existieren. Zeiger auf konstante Objekte werden 
vom Prozessor in eindeutiger Weise gekennzeichnet . 

Vorzugsweise wird bei der vorliegenden Prozessor- 
architektur in bekannter Weise ein Bereich des Spei- 
30 chers fur einen Programmstapel reserviert. Der Pro- 

grammstapel wird hierbei in einen Zeiger stapelbereich 
und einen Datenstapelbereich unterteilt, wobei jeweils 
die erste nicht vom Stapel belegte Position durch einen 
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Stapelindex angegeben wird, der in je einem reservier- 
ten Datenregister verwaltet wird. 

Werden mehrere Stapel verwendet, so werden die 
Stapelindizes der momentan inaktiven Stapel vorzugs- 
5 weise als Attribute in den zugehorigen Stapelobjekten 
abgelegt. Weiterhin werden die Stapelobjekte als sog. 
statische Objekte vorzugsweise nicht im Heap, sondern 
in einem vom Betriebssystem verwalteten statischen 
Speicherbereich abgelegt und Zeiger auf derartige 
10 Objekte (statische Zeiger) in besonderer Weise gekenn- 
zeichnet . 

Zur ef fizienten Implementierung der Prozessorar- 
chitektur wird jedes Zeigerregister vorzugsweise von 

15 einem Attributregister begleitet, in dem die Attribute 
des Objekts abgelegt werden, die zu dem mit dem Zeiger 
im Zeigerregister ref erenzierten Objekt gehoren. Bei 
dieser Ausgestaltung ist eine zusatzliche Pipeline- 
Stufe zum Laden der Attribute vorgesehen. Weiterhin 

20 wird in dieser Pipeline-Stuf e vorzugsweise ein Attri- 
but-Cache zur Beschleunigung der Zugriffe eingesetzt. 

Alle weiteren ftir die Programmausfuhrung erforder- 
lichen Pipeline-Stuf en und Funktionseinheiten sowie die 
ublichen Optimierungen wie bspw. Instruktions- und 

25 Da ten-Caches oder Einheiten zur Sprungvorhersage kdnnen 
bei einer Implementierung der vorliegenden Prozessorar- 
chitektur gemaiS des Standes der Technik realisiert 
werden. 



30 



Kurze Beschreibung der Zeichntmgen 

Die erfindungsgemaSe Prozessorarchitektur wird 
nachfolgend anhand eines Ausfuhrungsbeispiels in Ver- 
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bindung mit den Zeichnungen eingehend erlautert. 
Hierbei zeigen: 



Fig. 1 schematisch das Regis termodell der 

5 vorliegenden Prozessorarchitektur; 

Fig. 2 schematisch das Ob j ektmodell der 

vorliegenden Prozessorarchitektur; 

Fig. 3 schematise*, die Realisierung des 

Programmstapels als Stapelobjekt ; 

10 Fig. 4 eine Tabelle mit einer Klassifi- 

kation der zeigerbezogenen Befehle; 

Fig. 5 ein Beispiel fur die Realisierung 

des Objektlayouts far die vorlie- 
genden Prozessorarchitektur; 

15 Fig. 6 schematisch ein Zeigerregister mit 

Attributen; 

Fig. 7 ein Beispiel fiir die Realisierung 

einer Pipeline fur die vorliegende 
Prozessorarchitektur (vereinf achte 
20 Darstellung) ; und 

Fig. 8 die Zerlegung zeigerbezogener Be- 

fehle auf die Stufen einer Pipeline 
gemaS Figur 7. 



25 Wege zur Aus f iihrung der Erfindung 

Im Folgenden wird ein Beispiel fiir eine Ausgestal- 
tung der erf indungsgemaEen Prozessorarchitektur be- 
schrieben, die vor allem auf der Zielsetzung basiert, 
eine exakte Zeigeridentif izier\ing ohne die Verwendung 
30 von Kennzeichnungsbits (tags) zu erreichen, einen 
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allgemein verwendbaren RISC-Bef ehlsatz zu Grunde zu 
legen, der effizient implementiert werden kann, sowie 
keine unteilbaren Operationen vorauszusetzen, deren 
Ausftihrungszeit einige Taktzyklen tibersteigt. 

5 

Die dargestellte Prozessorarchitektur garantiert 
die Systeminvariante, dass 

1. jedes Speicherwort oder Register dahingehend 
identif iziert werden kann, ob es einen Zeiger dar- 

10 stellt oder nicht, und 

2. jeder Zeigerwert entweder Null ist oder eindeu- 
tig einem existierenden Objekt zugeordnet ist. 

Die vorliegende Prozessorarchitektur stellt ge- 
15 trennte Daten- und Zeigerregistersatze bereit, wie dies 
in Figur 1 schematisch verdeutlicht wird. Die im rech- 
ten Teil dargestellten Datenregister werden als Mehr- 
zweckregister eingesetzt, wahrend die im linken Teil 
dargestellten Zeigerregister fur den Zugriff auf Objek- 
20 te im Speicher genutzt werden. N p gibt hierbei die An- 
zahl der Zeigerregister, N d die Anzahl der Datenregi- 
ster an. Um der Systeminvariante zu genugen , muss 
sichergestellt werden, dass es nicht moglich ist, 
beliebige Werte in Zeigerregister zu schreiben, wie 
25 bspw. den Wert eines Datenregisters in ein Zeigerre- 
gister zu kopieren oder arithmetische Operationen mit 
Zeigerregistern durchzuf tihren . 



Das Speichermodell der vorliegenden Prozessor- 
30 architektur ist objektbasiert . Jedes Objekt setzt sich 
aus einem Datenbereich und einem Zeigerbereich zusam- 
men, die streng voneinander getrennt sind. Figur 2 
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zeigt den schematischen Aufbau eines derartigen Objekts 
mit den entsprechenden Zeigerworten im Zeigerbereich 
(linker Teil der Figur) und den Datenworten im 
Datenbereich (rechter Teil der Figur) des Objekts. Die 
5 Anzahl der Datenworte im Datenbereich wird mit dem 8- 
Attribut (8^0), die Anzahl der Zeiger im Zeigerbe- 
reich mit dem rc-Attribut (n £ 0) beschrieben. Die durch 
die Attribute beschriebene Grofie eines Objekts wird 
festgelegt, wenn das Objekt erzeugt wird und kann 
10 spater nicht mehr geSndert werden. Die Attribute sind 
Teil des Objekts und werden in diesem in einem geson- 
derten Attributbereich abgelegt. 

Der fur die vorliegende Prozessorarchitektur 
15 spezifische Teil des Bef ehlssatzes umfasst lediglich 
zeigerbezogene Befehle einschliefilich Lade- und Spei- 
cherbefehle. Die Ausgestaltung anderer Befehle , wie 
bspw, arithmetischer Befehle oder von Befehlen zur 
Programms t euerung kann unabhangig von der beschriebenen 
20 Architektur gewahlt werden und ist nicht Teil der vor- 
liegenden Erfindung. 

Der Befehlssatz der beschriebenen Architektur 
weist einen speziellen Objekterzeugungsbef ehl auf , der 

25 zur Erzeugung eines neuen Objekts und eines Zeiger s auf 
dieses Objekt dient. Der Objekterzeugungsbef ehl 
(Allocate Object) erhalt die Werte des rc- und 8-Attri- 
buts fur das zu erzeugende Objekt als Argumente und 
legt den Zeiger auf das neu erzeugte Objekt in einem 

30 Zeigerregister ab. Jedes Zeigerwort im Zeigerbereich 
des erzeugten Objekts wird mit Null initialisiert, 
bevor der Zeiger auf das Objekt ftir das Programm sicht- 
bar wird, Es gibt keinen Bef ehl zum Loschen eines 
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Objekts. Objekte konnen nur durch eine automatische 
Speicherbereinigung auf Prozessorebene geloscht werden. 

Lade- und Speicherbef ehle werden fttr den Zugriff 
5 auf Worte innerhalb eines Objekts eingesetzt. Die Pro- 
zessorarchitektur stellt ftir den Zugriff auf Zeiger- 
worte und Datenworte unterschiedliche Lade- und Spei- 
cherbef ehle zur Verftigung. Die „Lade Datum"- und 
„Speichere Datum" -Bef ehle bewegen Datenworte aus- 

10 schlieSlich zwischen Datenbereichen von Objekten und 
Datenregistern. Die ff Lade Zeiger"- und „Speichere 
Zeiger^-Befehle bewegen Zeiger ausschliefilich zwischen 
Zeigerbereichen von Objekten und Zeigerregistern. Die 
Lade- und Speicherbef ehle identif izieren das Speicher- 

15 wort, auf das zugegriffen werden soli, mit Hilfe eines 
Zeigerregisters, das den Zeiger auf das Objekt enthalt, 
und mit Hilfe eines ganzzahligen, positiven Index. Zur 
Berechnung der Indexwerte konnen - in Analogie zu den 
Adressierungsarten konventioneller Architekturen - ver- 

20 schiedene „Indizierungsarten w verwendet werden, die 

bspw. Datenregister, konstante Offsets und Skalierungs- 
faktoren verknupfen. 

Beim Zugriff auf ein Objekt mussen Bereichsiiber- 
prtifungen durchgeftthrt werden, urn sicherzustellen, dass 

25 keine Zugriffe auf Worte auEerhalb des jeweils referen- 
zierten Objekts moglich sind. Solche Zugriffe konnen 
katastrophale Folgen nach sich Ziehen und die Systemin- 
variante verletzen. Aus diesem Grund wird im Falle 
einer Bereichstiberschreitung der Speicherzugrif f abge- 

30 brochen und eine entsprechende Ausnahmebehandlung ein- 
geleitet. Aus ahnlichen Grunden werden Befehle abgebro- 
chen, die versuchen, einen Null-Zeiger zu deref erenzie- 
ren. 
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Die Attribute eines Objekts konnen durch zwei 
i/Lese Attribute "-Befehle abgefragt warden. 

5 Im Gegensatz zu der Vielzahl von „ Regis ter- zu- 

Register^-Befehlen, die in der Regel ftir Operationen 
auf Datenregister implementiert werden, wird durch die 
vorliegende Architektur ein stark beschrankter Satz von 
zwei Befehlen fur zeigerbezogene „ Register- zu- 
10 Register w -Befehle definiert. Der „Kopiere Zeiger*- 

Befehl kopiert den Inhalt eines Zeigerregisters in ein 
anderes Zeigerregister, wahrend der „Vergleiche 
Zeiger* -Befehl uberpruft, ob zwei Zeiger auf dasselbe 
Objekt verweisen. 

15 

Figur 4 zeigt eine Zusammenf assung der von der 
vorliegenden Prozessorarchitektur definierten zeiger- 
bezogenen Befehle und kategorisiert sie danach, ob sie 
Zeigerregister lesen, schreiben oder deref erenzieren. 
20 Das Register, das jeweils gelesen, geschrieben oder 
deref erenziert wird, ist fett gedruckt. 

Aufgrund der unstrukturierten und hdehdynamischen 
Natur von Programmstapeln stellen diese eine der 

25 groEten Herausf orderungen hinsichtlich der Zeigeriden- 
difizierung im Rahmen einer automatischen Speicherbe- 
reinigung dar. Bei der vorliegenden Prozessorarchitek- 
tur wird der Programmstapel als Stapelobjekt angesehen, 
das - wie jedes Objekt - einen Datenbereich und einen 

30 Zeigerbereich aufweist und damit als zwei getrennte 

Stapel angesehen werden kann. Ein Zeigerregister wird 
reserviert, um den Zeiger auf das Stapelobjekt zu 
halten. in jedem der beiden Stapelbereiche wird ein 
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Stapelindex eingesetzt, um den entsprechenden Bereich 
in den tatsachlichen Stapel und einen momentan unbeleg- 
ten Bereich einzuteilen. Der Stapelindex bezieht sich 
im vorliegenden Beispiel auf die erste unbelegte Spei- 
5 chers telle. Ein Stapelindex von 0 repr^sentiert einen 
leeren Stapel. Die beiden Stapelindizes werden als 
Datenstapel index (dsix) und Zeigerstapelindex (psix) 
bezeichnet. Jeder dieser Indizes wird in einem speziell 
daftir reservierten Datenregister gehalten. 

10 Wenn das Stapelbbjekt wie ein gewohnliches Objekt 

behandelt wird, so kann das System nicht unterscheiden, 
ob ein Zeiger zum aktuell belegten Zeigerstapel oder 
zum unbelegten Teil des Zeigerstapelbereiches gehort. 
Da jedes Wort im Zeigerstapelbereictt als Zeiger identi- 

15 fiziert wird, kann der ungenutzte Bereich des Zeiger- 
stapelbereichs viele Zeiger enthalten, die auf nicht 
mehr benotigte Objekte zeigen. Ein Speicherbereiniger 
(garbage collector) konnte diese Objekte nicht frei 
geben, da noch Zeiger auf diese Objekte vorhanden sind. 

20 Eine mSgliche Losung dieses Problems besteht darin, je- 
den Zeigerwert mit Null zu tibersclireiben, sobald der 
entsprechende Zeiger vom Stapel entfernt wird. Dies 
ftilirt jedoch zu einem unerwOnschten Overhead, insbeson- 
dere dann, wenn mehrere Zeiger vom Stapel entfernt 

25 werden sollen, wie das bspw. beim Abbau eines Stapel- 
rahmens am Ende eines Unterprogramms der Fall ist. 

Fur das hier beschriebene Beispiel einer vorteil- 
haften Ausgestaltung der Prozessorarchitektur wird 
daher eine Losung gewahlt, die die dynamische Gr6fie 

30 eines Stapels beriicksichtigt . Hierbei wird das Stapel- 
objekt, wie in Figur 3 veranschaulicht , durch zwei 
Attributpaare beschrieben, von denen ein Paar (tc, 8) 
die aktuelle StapelgrSfie und ein zweites Paar (II, A) 
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die maximale Stapelgr6£e angibt. Das 7t-Attribut ent- 
spricht dabei dem Wert des Zeigerstapelindex psix, das 
8-Attribut dem Wert des Dat ens tapel index dsix. Die 
Stapelattribute II und A werden in Systemregi stern 
5 gehalten, die fur Anwenderprograinme nicht sichtbar 
sind. Hinsichtlich der Zeigeridentif izierung und der 
Systeminvariante werden lediglich Zeiger mit Indizes 
kleiner als % als Zeiger angesehen. 

Speicherworte innerhalb des Stapels werden durch 

10 gewohnliche Lade- und Speicherbef ehle angesprochen. 

Worte konnen vom Stapel entfernt werden, indem der Wert 
des entsprechenden Stapelindex mittels gewdhnlicher 
arithmetischer Befehle verringert wird, Zur Einhaltung 
der Systeminvariante wird zur Ablage eines Zeigers auf 

15 dem Zeigerstapel ein spezieller Befehl bereitgestellt , 
der in nicht unterbrechbarer Weise zuerst den Zeiger an 
der ersten unbelegten Speicherstelle des Zeigerstapel- 
bereiches ablegt xand den Zeigerstapelindex erboht. Dies 
ist gleichzeitig der einzige Befehl, mit dem der 

20 Zeigerstapelindex erhoht werden kann. 

Bei der bisher beschriebenen Prozessorarchitektur 
kann ausschlieSlich tiber Zeiger auf den Speicher zuge- 
griffen werden, und die einzige Moglichkeit zur Erzeu- 

25 gung von Zeigern besteht im Anlegen neuer Objekte mit 
Hilfe des Objekterzeugungsbefehls. Es sollte jedoch 
auch moglich sein, auf konstante Daten zuzugreifen, die 
bspw. als Teil des Programmcodes bereits vor dem Start 
des Programmes existieren. Beispiele fur solche kon- 

30 stanten Daten sind konstante Zeichenketten Oder vom 

Compiler generierte Strukturen wie bspw. Verzweigungs- 
tabellen oder Typbeschreibungen. 
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Das vorliegenden Beispiel einer vorteilhaf ten 
Ausgestaltung der Prozessorarchitektur ftihrt daher 
konstante Objekte ein. Ein konstantes Objekt ist 
hierbei ein unverSnderbares Objekt, das als Teil des 
Prograramcodes oder in einem speziellen Bereich abge- 
speichert wird, der fur konstante Objekte reserviert 
ist. Fiir die Erzeugung von Zeigern auf konstante 
Objekte, nachfolgend als konstante Zeiger bezeichnet, 
wird ein spezieller ff Erzeuge konstanten Zeiger U -Befehl 
verwendet. Speicherzugrif f e uber konstante Zeiger- sind 
auf Lesezugriffe beschrankt, und der Zeigerbereich 
eines konstanten Objekts darf ausschlie&lich konstante 
Zeiger oder Null-Zeiger enthalten. Konstante Objekte 
werden von gewohnlichen Objekten durch ein <p-Attribut 
unterschieden, das zur Unterscheidung spezieller Arten 
von Objekten bereitgestellt wird. 

In vielen Systemen werden getrennte Programmstapel 
ftir unterschiedliche Betriebsarten wie bspw. Anwender- 
modus und Betriebssystemmodus verwendet. Daruber hinaus 
erfordern Systeme mit mehreren nebenlauf igen Ausfuh- 
rungsfaden (multi- threaded systems) separate Programm- 
stapel fur jeden Ausftihrungsfaden. Alle diese Stapel 
werden ublicherweise vom Betriebssystem verwaltet und 
bef inden sictx nicht in dem von der automatischen Spei- 
cherbereinigung uberwachten Speicherbereich (Heap) . 

Um es dem Betriebssystem zu ermoglichen, Speicher- 
bereiche auSerhalb des Heap-Speicherbereiches zu ver- 
walten, werden statische Objekte bereitgestellt. Stati- 
sche Objekte werden ausschlieSlich im Betriebssystem- 
modus erzeugt und in einem speziell daftir vorgesehenen 
Speicherbereich angeordnet. Statische Objekte werden 
ebenfalls tiber das (p-Attribut identif iziert . Zeiger auf 
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statische Objekte (statische Zeiger) sind ftir Anwender- 
programme niemals sichtbar. 

Zur Eirihaltuiig der Systeminvariante muss jeder 
Zeiger in einem neu erzeugten Objekt mit dem Null-Wert 
initialisiert werden, bevor der zugehorige Objekterzeu- 
gungsbefehl abgeschlossen werden kann. Deshalb ist die 
Ausftihrungszeit fur den Ob j ekterzeugungsbef ehl nicht 
durch eine kleine Zeitkonstante begrenzt. Dies ist fiir 
harte Echtzeitanwendungen nicht akzeptabel. 

Urn den Obj ekterzeugungsbef ehl unterbrechbar zu 
gestalten, werden in der beschriebenen vorteilhaf ten 
Ausgestaltung der Prozessorarchitektur uninitialisierte 
(genauer: unvollstSndig initialisierte) Objekte einge- 
f uhrt . Uninitialisierte Objekte werden dann und nur 
dann erzeugt, wenn der Zuweisungsbef ehl vor der Fertig- 
stellung eines Objekts unterbrochen wird. Zeiger auf 
uninitialisierte Objekte sind nur im Betriebssystem- 
modus sichtbar und diirfen niemals deref erenziert 
werden. Uninitialisierte Objekte werden - wie statische 
und konstante Objekte - durch das <p-Attribut identifi- 
ziert. 

Die beispielhaft beschriebene vorteilhaf te Ausge- 
staltung der Prozessorarchitektur unterstiitzt folglich 
vier unterschiedliche Arten von Objekten: normal e dyna- 
mische Objekte, uninitialisierte dynamische Objekte, 
konstante Objekte und statische Objekte. Das <p-Attribut 
wird zur Unterscheidung der Objektarten eingesetzt und 
kann einen der vier Werte (norm, uini, const, stat) an- 
nehmen . In einer Implementierung der Architektur kann 
das <p-Attribut im Zeiger auf ein Objekt und/oder im 
Objekt selbst abgelegt werden. 
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Normale dynamische Objekte und uninitialisierte 
dynamische Objekte befinden sich im Heap-Speicherbe- 
reich, statische Objekte im statischen Speicherbereich 
und konstante Objekte in dem fur den Programmcode 
und/oder konstante Daten vorgesehenen Speicherbereich. 
Da statische und uninitialisierte Objekte auf den 
Betriebssystemmodus beschrSnkt sind, werden sie als 
Systemobjekte bezeichnet. 

Unter dem Gesichtspunkt der automatischen 
Speicherbereinigung konnen die vier Objektarten dadurch 
charakterisiert werden, wie sie von einem kompaktieren- 
den Speicherbereiniger behandelt werden. Gewohnliche 
dynamisehe Objekte mussen nach Zeigern durchsucht und . 
bei einer Kompaktierung verschoben werden. Statische 
Objekte mussen zwar nach Zeigern durchsucht, dxirfen 
aber nicht verschoben werden. Uninitialisierte Objekte 
dagegen mussen wahrend der Kompaktierung verschoben 
werden, dtirfen aber nicht nach Zeigern durchsucht 
werden, da sie ungultige Zeiger enthalten k6nnen. 
SchlieElich miissen konstante Objekte vom Speicherberei- 
niger weder nach Zeigern durchsucht noch verschoben 
werden. 

Eine mogliche Implement ierung der vorgeschlagenen 
Prozessorarchitektur wird im Folgenden beispielhaft 
eriautert. Fur die Implementierung wird eine Wortgrofie 
von 32 Bit angenommen. Der Speicher ist byteweise 
adressierbar, um innerhalb des Datenbereiches auch 
Byte- und Halbwortzugrif f e zu ermoglichen. Worte mussen 
an durch vier teilbaren Adressen ausgerichtet werden. 

Ein beispielhaf tes Layout eines Objekts im 
Speicher ist in der Figur 5 dargestellt. Jedes Objekt 
besteht aus einem Datenbereich, einem Zeigerbereich und 



103396PDE 

Universitat Stuttgart 



- 23 - 



einem Attributbereich. Aus Ef f izienzgriinden sind die 
Objekte an durch acht teilbaren Adressen ausgerichtet, 
wodurch unter Umstanden ein Fiill-Bereich zwischen zwei 
Objekten erforderlich werden kann. Der Attributbereich, 
der fur Nutzerprogramme unsichtbar ist, beinhaltet die 
n und S-Attribute des Objekts. Aufgrund der Unter- 
stutzung von Byte- und Halbwortoperanden andert die 
vorliegende Implementierung die Definition von n und 5 
leicht, da sie nun die Anzahl von Bytes anstelle der 
Anzahl der Worte in dem entsprechenden Bereich be- 
schreiben. 

Da n ein Vielf aches von vier sein muss, bleiben im 
Speicherwor t , das ftir das rc-Attribut verwendet wird, 
zwei Bits unbelegt. Diese konnen zur Ablage des <p- 
Attributs (oder Teilen davon) und/oder von einem 
Speicherbereiniger verwendet werden. 

Die Zeiger enthalten direkt die physikalische 
Speicheradresse des Objekts. Da die Objekte nach 
Doppelworten ausgerichtet sind, belegt die Objekt - 
adresse lediglich 29 Bits eines Zeigerwortes . Die 
verbleibenden drei Bits konnen zur Ablage des <p- 
Attributs (oder Teilen davon) und/oder von einem 
Speicherbereiniger verwendet werden. 

Vor dem Zugriff auf ein Objekt muss en die Attri- 
bute des Objekts bekannt sein, da diese far die 
Bereichsiiberpriifung vor dem Zugriff benotigt werden, 
und, im Falle eines Ob j ektlayouts gemaS Figur 5, im 
Falle eines Datenzugrif f s zusatzlich fur die Adresser- 
zeugung erforderlich sind. 

Da das Laden der Attribute aus dem Speicher vor 
jedem Objekt zugriff mit einem grofien Overhead verbunden 
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ist, wird jedem Zeigerregister ein Attributregister 
beiges tellt, wie dies in der Figur 6 schematisch darge- 
stellt ist. Wenn ein Zeigerregister einen Wert enthalt, 
der nicht Null ist, beinhaltet das korrespondierende 
Attributregister die Attribute des Objekts, auf das das 
Zeigerregister verweist. Auf diese Weise wird der 
Aufwand ftir die Deref erenzierung eines Zeigerregisters 
so gering wie der Aufwand fur die Adresserzeugung in 
konventionellen Architekturen. Die Bereichsiiberprufung 
selbst ist mit keinen LeistungseinbuBen verbunden, da 
sie parallel zur Adressberechnung durchgefiihrt werden 
kann. 

Die Attributregister haben jedoch ihren Preis: 
Wenn ein Zeiger aus dem Speicher geladen wird, miissen 
audi die zugehorigen Attribute in die Attributregister 
geladen werden. Hinzu kommt, dass der Ort der Attribute 
im Speicher erst bekannt ist, wenn das Laden des 
Zeigers abgeschlossen ist. 

Dieses Problem kann im Falle einer RISC-Architek- 
tur ef fizient durch eine zusatzliche Pipelinestuf e nach 
der xiblichen Speicherstuf e gelost werden. Diese zusatz- 
liche Stuf e wird als Attributstuf e bezeichnet und ver- 
wendet einen At tribut -Cache, tun Attributzugrif f e in den 
meisten Fallen ohne LeistungseinbuBen auszufiihren. Der 
Aufbau des Attribut-Cache ist dem eines gewohnlichen 
Daten-Caches ahnlich. Der Attribut-Cache wird durch die 
oberen 29 Bits eines Zeigers adressiert und ermoglicht 
das Lesen oder Schreiben der % und 8-Attribute in einem 
einzigen Schritt. Der wesentliche Unterschied zu einem 
Daten-Cache besteht in der GroEe der Cache-Zeilen. 
Wahrend Cache-Zeilen in Daten-Caches ublicherweise 8 
Worte umfassen, weist eine Zeile des Attribut-Cache 
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eine Breite von 2 Worten auf und enthalt lediglich die 
Attribute eines einzelnen Objekts. 

Figur 7 zeigt die Grundstruktur der implemen- 
tierten Pipeline und Figur 8 die Zerlegung aller 
zeigerbezogenen Befehle auf die einzelnen Pipeline- 
Stufen. Zur Veranschaulichung wird die Abarbeitung der 
beiden aufw&idigsten Befetile beispielhaft beschrieben. 

1. „Lade Zeiger* -Befehl: 

In der Ausftihrungsstufe der Pipeline berechnet die 
Adresserzeugungseinheit (AGU: Address Generation Unit) 
die Speicheradresse des zu ladenden Zeigers und ftihrt 
parallel dazu die von der Architektur vorgeschriebenen 
Lauf zeittests wie bspw. Bereichsuberpriifungen und Null- 
zeigertests durch. In der Speicherstuf e wird die be- 
rechnete Adresse benutzt, um den Zeiger aus dem Objekt- 
Cache zu lesen. Der geladene Zeiger adressiert dann den 
At tribut -Cache, um die Attribute aus dem Objekt zu 
laden, auf das der geladene Zeiger zeigt. SchlieSlich 
wird der geladene Zeiger zusammen mit den geladenen 
Attributen in den Regis tersatz geschrieben. 

2 . Ob j ekterzeugungsbef ehl : 

Die Grofie des zu erzeugenden Objekts wird mit Hilfe 
zweier Datenoperanden bestimmt, die aus der Dekodier- 
stufe in die Ausfuhrungsstuf e weitergereicht werden. In 
der Ausfiihrungsstufe ist die Zeigererzeugungseinheit 
(PGU: Pointer Generation Unit) ftir die Erzeugung des 
Zeigers auf das neue Objekt zustandig. Im Falle eines 
kompaktierenden Speicherbereinigers kann die PGU die 
Startadresse des neuen Objekts sehr einfach dadurch 
bestimmen, dass die Objektgr6£e zum Inhalt eines 
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Systemregisters addiert wird, das stets auf das letzte 
belegte Wort in dem Bereich des Heaps zeigt, der ftir 
das Anlegen neuer Objekte verwendet wird. Die PGU wird 
durch die AGU untersttitzt, die die fur die Zeigerini- 
tialisierung erf orderliclien Adressen erzeugt. Bei einem 
Objekt-Cache mit Cache-Zeilen von 8 Worten konnen in 
einem Taktzyklus bis zu 8 Zeigerworte gleichzeitig 
initialisiert werden. Auf diese Weise durchlSuft der 
Erzeugungsbefehl die Ausfiihrungsstuf e ohne Verzogerung, 
wenn die Startadresse des Objekts innerhalb eines Takt- 
zyklus berechnet werden kann und wenn alle Zeiger ira 
Objekt der gleichen Cache-Zeile angehoren. Falls dies 
nicht der Fall ist, wird die Pipeline angehalten, bis 
die Initialisierung abgeschlossen ist oder eine Unter- 
brechung auftritt, SchlieSlich werden die Attribute des 
neu generierten Objekts in den At tribut -Cache und der 
Zeiger zusammen mit seinen Attributen in den Register - 
satz geschrieben. Falls ein unterbrochener Objekterzeu- 
gungsbefehl am Ende der Pipeline ankommt , wird der Zu- 
stand der unterbrochenen Obj ekterzeugung in ein System- 
register geschrieben und das unvollstandig initiali- 
sierte Objekt mit dem <p-Attribut ftir uninitialisierte 
Objekte gekennzeichnet . Die Initialisierung wird wieder 
aufgenommen, sobald der Ausfubrrongskontext (Befehls- 
folgezahler, Systemregister) des unterbrochenen Pro- 
gramms wieder hergestellt ist. 

Die Funktionsfahigkeit der vorgeschlagenen Archi- 
tektur wurde anhand eines funktionierenden Prototypen 
nachgewiesen. In diesem Prototypen ist der Speicherbe- 
reiniger als mikroprogrammierter Koprozessor reali- 
siert, der eng mit der Pipeline des Hauptprozessors 
zusaramenarbeitet. Die Synchronisation zwischen Pro- 
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zessor und Koprozessor ist komplett in Hardware reali- 
siert. Der Prozessor und der Koprozessor fur die 
Speicherbereinigung sind in VHDL beschrieben und 
gemeinsam far einem modernen programmierbareren 
Logikbausteins syntbetisiert . Es existieren weiterhin 
ein prototypischer Java-Compiler sowie die Implementie- 
rung einer Untermenge der Java-Klassenbibliotheken f\ir 
die Architektur. 
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Patentanspruche 



1. Prozessorarchitektur, bei der der Zugriff auf 
einen Speicber tiber Zeiger erfolgt, die auf 
Objekte verweisen, dadurch gekennzeichnet, 
dass in den Objekten Zeiger in einem Zeigerbereich 
und Daten in einem Datenbereich getrennt voneinan- 
der abgelegt werden, wobei die Zeiger eine Spei- 
cheradresse des Objekts enthalten, auf das sie 
verweisen und die Objekte mit Attributen versehen 
werden, die im Objekt selbst abgelegt werden und 
die eine Lange des Zeigerbereich.es und eine Lange 
des Datenbereiches beschreiben, und 
dass der Prozessor einen Registersatz mit ge- 
trennten Daten- und Zeigerregi stern bereitstellt, 
von denen die Zeigerregister fur den Zugriff auf 
Objekte im Speicher verwendet werden. 

2. Prozessorarcbitektur nach Anspruch 1, 
dadurch gekennzeichnet , 

dass der Prozessor gewahrleistet , dass jeder 
Zeiger nur entweder einen vorgegebenen Null-Wert 
oder die Speicheradresse eines existierenden 
Objekts enthait. 

3 . Prozessorarcbitektur nach Anspruch 1 oder 2 , 
dadurch gekennzeichnet, 

dass ein Befehlssatz mit getrennten Befehlen fur 
Daten- und Zeigeroperationen eingesetzt wird. 
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4. Prozessorarchitektur nach einem der Anspruche 1 
bis 3, 

dadurch gekennzeichnet , 

dass Lade- und Speicheroperationen fiir Zeiger 
5 ausschliefilich Zeiger aus den Zeigerbereichen der 

Objekte in Zeigerregister laden bzw. den Inhalt 
von Zeigerregistern in den Zeigerbereichen der 
Objekte speichern, und 

dass Lade- und Speicheroperationen fiir Da ten 
10 ausschlieElich Daten aus den Datenbereichen der 

Objekte in Datenregister laden bzw. den Inhalt von 
Datenregistern in den Datenbereichen der Objekte 
speichern. 

15 5. Prozessorarchitektur nach einem der Anspruche 1 
bis 4, 

dadurch gekennzeichnet , 

dass ein Befehlssatz mit einem Objekterzeugungs- 
befehl verwendet wird, der alle Zeiger im Zeiger- 
20 bereich eines erzeugten Objekts mit einem Null- 

Wert initialisiert, bevor auf das erzeugte Objekt 
zugegriffen werden kann. 

6. Prozessorarchitektur nach Anspruch 5, 
25 dadurch gekennzeichnet # 

dass der Objekterzeugungsbef ehl unterbrochen und 
zu einem spateren Zeitpunkt fortgesetzt werden 
kann. 



30 7. Prozessorarchitektur nach Anspruch 6, 
dadurch gekennzeichnet/ 

dass beim Unterbrechen des Objekterzeugungsbef ehls 
unvollstandig initialisierte Objekte erzeugt 
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werden, die vom Prozessor eindeutig von 
vollstandig initialisierten Objekten unterschieden 
wer den . 

8. Prozessorarchitektur nach einem der Anspriiche 1 
bis 7 , 

dadurch gekennzeichnet, 

dass der Prozessor konstante Objekte unterstutzt, 
die in einem separaten Speicherbereich gehalten 
werden, der zur Programmlauf zeit ausschliefilich 
gelesen wird, und 

dass Zeiger auf konstante Objekte vom Prozessor in 
eindeutiger Weise gekennzeichnet werden* 

9. Prozessorarchitektur nach einem der Anspriiche 1 
bis 8, 

dadurch gekennzeichnet, 

dass ein Programmstapel verwendet wird, der in 
einen Zeigerstapelbereich und in einen Datensta- 
pelbereich unterteilt ist, wobei eine LSnge des 
belegten Teils in jedem der beiden Stapelbereiche 
durch je einen Stapelindex angezeigt wird, der in 
je einem dafiir reservierten Datenregister verwal- 
tet wird. 

10. Prozessorarchitektur nach Anspruch 9, 
dadurch gekennzeichnet , 

dass zur Ablage eines Zeigers auf dem Zeigerstapel 
ein Befehl verwendet wird, der in nicht unter- 
brechbarer Weise sowohl den entsprechenden Zeiger 
auf dem Zeigerstapel ablegt als auch den Zeiger - 
stapelindex erhoht. 
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ll . Prozessorarchitektur nach einem der Anspriiche 1 
bis 10, 

dadurch gekennzeichnet, 

dass der Prozessor statische Objekte unterstiitzt, 
die in einem separaten, von einem Betriebssystem 
verwalteten Speicherbereich gehalten werden, und 
dass Zeiger auf statische Objekte vom Prozessor in 
eindeutiger Weise gekennzeichnet werden. 

12. Prozessorarchitektur nach Anspruch 9 in Verbindung 
mit Anspruch 11 oder Anspruch 10 in Verbindung mit 
Anspruch 11, 

dadurch gekennzeichnet, dass 

fur den Programmstapel statische Objekte verwendet 
werden, wobei die im Objekt enthaltenen Attribute 
bei einem nicht aktiven Programmstapel jeweils die 
Lange eines tatsachlich belegten Teils des Stapel- 
bereichs beschreiben. 



13 . Prozessorarchitektur nach einem der Anspriiche 1 
bis 12, 

dadurch gekennzeichnet, 

dass jedem Zeigerregister ein Attributregister 
zugeordnet wird, in das die Attribute des Objekt s 
geschrieben werden, auf das der Zeiger im Zeiger- 
register verweist. 

14. Prozessorarchitektur nach Anspruch 13, 
dadurch gekennzeichnet, 

dass eine Pipeline mit einer zusatzlichen 
Pipeline-Stufe zum Laden der Attribute eingesetzt 
wird. 
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15. Prozessorarchitektur nach Anspruch 13 Oder 14, 
dadurch gekennzeichnet , 

dass ein Attribut-Cache eingesetzt wird. 

16. Prozessorarchitektur nach einem der Ansprtiche 1 
bis 15, 

dadurch gekennzeichnet, 

dass ein RISC-Bef ehlssatz verwendet wird. 

17. Prozessorarchitektur nach einem der Ansprtiche 1 
bis 16, 

dadurch gekennzeichnet, 

dass der Prozessor eine automat ische Speicher- 
bereinigung durchfiihrt. 

18. Prozessor, in den die Prozessorarchitektur nach 
einem der vorangehenden Ansprtiche iraplementiert 
ist . 



19. Verwendung der Prozessorarchitektur nach einem der 
Ansprtiche 1 bis 17 ftir eingebettete Systeme. 
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Zus aimaenf as sung 



Die vorliegende Erfindung betrifft eine objekt- 
basierte Prozessorarchitektur , die eine exakte Zeiger- 
identif izierung dadurch ermoglicht, dass Zeiger und 
5 Daten im Speicher und in den Prozessorregistern streng 
voneinander getrennt werden . Der Zugriff auf den 
Speicher erfolgt ausschliefilich fiber Zeiger, die auf 
Objekte verweisen. Ein Objekt beirihaltet getrennte 
Bereiche far Zeiger und Daten sowie ein Attributfeld 

10 zur Beschreibung der LSnge der beiden Bereiche. Sowohl 
die Zeiger in den Zeigerregi stern als auch die Zeiger 
in den Zeigerbereichen der Objekte enthalten direkt die 
Adresse der Objekte, auf die sie verweisen. Die vorge- 
schlagene Prozessorarchitektur ermoglicht die Inte- 

15 gration einer automat ischen Speicherbereinigung, die 
ganz oder teilweise in Hardware implementiert werden 
kann. Durch die Hardware-Untersttitzung kann eine echt- 
zeitfahige Speicherbereinigung auf besonders effiziente 
Weise realisiert werden. 
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Befehle, die Zeigerregister lesen 

Speichere Zeiger (store pointer) sp py[index] := pz 

Kopiere Zeiger (copy pointer) cpp px := pz 

Vergleiche Zeiger (compare pointers) cmpp dx := py.pz 



Befehle, die Zeigerregister schreiben 








Erzeuge Objekt (allocate object) 


ale 


px 


:= dy.dz 


Lade Zeiger (load pointer) 


IP 


px 


:= pypndex] 


Kopiere Zeiger (copy pointer) 


cpp 


px 


:= pz 


Erzeuge konst. Zeiger (create const, pointer) 


ccp 


px 


:= dy 



Befehle, die Zeigerregister dereferenzieren 






Lade Datum 


(load data) 


Id 


dx := py[index] 


Lade Zeiger 


(load pointer) 


IP 


px := pypndex] 


Speichere Datum 


(store data) 


sd 


pypndex] := dz 


Speichere Zeiger 


(store pointer) 


sp 


pypndex] := pz 


Lese ic-Attribut 


(read n- attribute) 


pattr 


dx := py 


Lese 8-Attribut 


(read 8-attribute) 


dattr 


dx :- py 



dx, dy, dz Datenregister 
px, py, pz Zeigerregister 
index Ausdruck fur Indizierungsart 



Fig. 4 
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Fig. 8 



